A common standard continues to evolve for the multiplexing of bitstreams from several audio, video, and/or auxiliary data sources. This standard, developed by the ISO Moving Picture Experts Group (MPEG), is set forth in draft form in a document entitled "Coding of Moving Pictures and Associated Audio" (ISO/IEC 13818 published by the ISO/IEC Copyright Office, Geneva, Switzerland), and hereby incorporated herein by reference. The MPEG standards provide for the transmission of digital information from multiple signal sources by dividing the digital data into a number of packets. The packets are then multiplexed onto a single data channel, allowing a relatively large number of users to transmit data over a common data channel.
A common transport stream syntax is required by the MPEG-2 audio-video coding standard. All audio, video and auxiliary information to be carried within a given data channel is divided into 188 byte long transport packets. Each transport packet is subdivided into a header and a payload. The header carries information to identify the type of data that is carried within the payload and information required to decode the transport packet stream. Of some significance to this invention is the presence of a program clock reference (PCR) value. The PCR is a 42-bit value that represents time references from a relative system time clock (STC) within an MPEG-2 encoder. Of the 42 bits, the upper 33 bits are referred to as the "PCR base", and express a value of the encoder system time clock in 90 kHz time base units. The remaining 9 bits of the PCR value are referred to as the "PCR extension", and express a value of the system time clock in 27 MHz time base units. The MPEG-2 standard requires that the PCR be provided at intervals of no more than 100 ms in the transport stream.
The PCR values within the MPEG-2 transport stream are used to accurately recover the encoder clock in the MPEG-2 decoder. It is necessary to maintain accurate rate matching between the encoder clock used to encode the data and the decoder clock used to decode the data in order to properly demultiplex and decode the audio and video data. The individual audio and video streams are provided with presentation time-stamps (PTSs) to indicate to the MPEG-2 decoder when to present the individual frames of video and audio data to the user. The value of each PTS is ultimately dictated by the frequency of the encoder clock, which clocks a system time clock in the MPEG-2 encoder. When encoding the data, the MPEG-2 encoder inserts the PTSs into the PES stream based on samples of the system time clock. The decoder must therefore operate at the same frequency as the encoder clock if the data is to be properly presented to a user. For purposes of this description, rate matching between the encoder clock and the decoder clock implies that the clocks are operating at the same frequency, but with a possible phase offset between them.
A difference in the encoder and decoder clock will contribute to the occurrence of a frame skip or a frame hold. For example, if an encoder clock is operating at a frequency slightly less than 27 MHz and a decoder clock is operating at a frequency slightly greater than 27 MHz, eventually the relative time represented by each clock will be separated by a time equal to the time it takes to display one frame of audio or video data. In most video decoders, a difference of one frame time is sufficient to cause a frame skip or a frame hold. Even clocks operating within a relatively close frequency of each other will eventually vary sufficiently to cause a frame skip or a frame hold, obviously a condition that is annoying to a viewer.
To synchronize the decoder clock with the encoder clock, the MPEG-2 standard suggests that the PCR values be used to implement a particular clock recovery system. Unfortunately, implementing the suggested recovery system has proven to be difficult to achieve. Various attempts have been made to avoid the expense of the suggested MPEG-2 hardware architecture. For example, MPEG-2 decoders have been developed that recover an encoder clock using only software routines. In a typical software solution, the transport stream packets are stored in a large memory buffer as they are received. PCRs within the transport packets are then recalled from memory and compared with a STC maintained by a microprocessor. This software method for recovery of the encoder clock has also proven unsuccessful, however, because the time sense that is inherently associated with the PCR is usually lost by the time the software routine processes the PCR.
Due to the difficulties in implementing the MPEG-2 suggested hardware solution for clock recovery, and the timing problems inherent in recovering a clock using a purely software solution, several MPEG-2 decoders have opted to forego clock recovery. These solutions focus on maintaining an accurate 27 MHz clock in the decoder, on the assumption that the encoder clock will also be closely kept at 27 MHz. However, as discussed above, even a small difference between the encoder clock and the decoder clock will eventually cause the decoder buffers to underflow or overflow. Solutions that have attempted to operate without synchronizing with the PCR values have thus had problems with buffer misbehavior, frame holds, frame skips, and similar anomalies.
The clock recovery system disclosed herein is directed to overcoming the above-described problems by providing separate STC registers that can be updated independently, but also to provide a convenient means for simultaneous updating multiple STC registers with a single write access when needed. Further, although the concepts presented herein are explained with reference to the audio and video decoders of an MPEG decode system, the concepts are applicable to updating any two or more counters where such independent yet synchronizable characteristics are desirable.